… applications (#34132)

Some CDK methods apply mutating Aspects on behalf of users. Since #32333, these Aspects have a priority of `MUTATING` to classify their behavior.

If a user-applied Aspect (priority `DEFAULT`) now configures the same property as an implicitly added Aspect:

* Before that change, the relative execution order depended on the location of the Aspects in the construct tree.
* After that change, the user Aspect always "wins" (executes last) because its priority is higher.

In this change, we roll back to the behavior from pre-2.172.0, and introduce a feature flag which gives the Aspects a priority only if the feature flag is enabled. This introduces the feature flag:

```json
{
  "context": {
    "@aws-cdk/core:aspectPrioritiesMutating": true
  }
}
```

Which sets the priority of Aspects added on your behalf a priority of `MUTATING` (200) (instead of the default `DEFAULT`, 500).

* If you have given your own Aspect a priority of `MUTATING` already to make sure it can get overridden by another Aspect  of priority `MUTATING`, this current change will not affect you (either with or without feature flag).
* If you have come to rely on the new default priority being low already, you can set the above feature flag to re-enable the new behavior.

-----------

Did not touch the following Aspects:

- In `integ-tests-alpha`: overriding logical IDs in assertions stacks does not affect production infrastructure.
- Tags: tags are exclusively manipulated through the official APIs, so there no conflict between custom and implicit Aspects.
- CDK Pipelines: there cannot be a conflict because the customer can't create a default pipeline before the implicit Aspect.

This PR also introduces some slight rendering and documentation changes to the feature flags to improve clarity of the purpose of certain fields and the produced report.

See CHANGELOG

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*